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S’JWIIARY 


■T, Various data transfer capabilities are required for user traffic. 

The set of rules governing exchanges is called a protocol, which 
is a variety of language. Protocols use communications tools on 
;■ which assumptions must be made. In particular they are not error free. 

.;; Protocol implementations are distributed machines whose components 
"jj must be synchronized. Error detection and back-tracking are neces- 
■ sary functions, and require internal communication for contrdl 
■; ; information. 

At the lowest level one needs a basic message transfer capability 
;; insuring reliable communications over an unsafe medium. This can 
"lip, .be achieved using named messagt s and acknowledgements, with a few 
:■> other limited assumptions. Varieties of communication procedures 
h.i -are actually based on this - simple scheme. Options arise in m.ana- 
-l ; ging the message name space. A window technique reduces overhead 
_)g while allowing non sequential transfers. 

JJ: _ _ _ 

i; User protocols implement various tools tailored to common reauirc- 
7fj:ments. There are discussions about the proper localization of func- 
.jg tions in the system, hierarchy. Server protocols are typical cases 
17 of distributed machines requiring a specialized user language, and 
■ig .an internal cotmunication machinery. The Arpanet file transfer 
in protocol is discussed. 

“-.Host protocols are a mixture of functions which can be put to work 
-—independently. They should be stripped down so as to provide just 
.d~. a basic communications layer allowing arbitrary extensionsOther . 
approaches are possible. 


This paper has been presented at the NATO International Advanced 
Study Institute, University of Sussex, Brighton, 9-15 September 1973, 
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I. USER REQUIREMENTS 


Programming a computer has a variety of acceptations. E.g. : 

. Write a program in assembly language to develop ?. tape handler 
, Use. an access method to update an index-sequential file 
. Write a COBOL program 
. Sort a file using a library processor 
. Submit a job from a remote.card reader 

. L^gin ard type commands to a time-sharing system, then work with 
' a conversational text-editor. 

All these activities require using some kind of language, typical¬ 
ly several, depending on which component or which level of system, 
is to be dealt with. Each language is supposedly well defined, and 
supported by a gamut of tools : manuals, compilers, interpreters, 
debugging aids. In many C:ses components can be implemented in 
one language, handled 'with another, and used as a building block 
(macho, sub-routine, processor) in the context of yet another 
language. All that makes up the traditional resource environment 
of a computer system. 

Computer networks have brought about an additional set of user 
needs, owing to the geographical dispersion and the heterogeneity 
of their resources. Furthermore, the practical implementation of 
appropriate user tools has to cope with specific problems resul¬ 
ting from present communications technologies. Investigations 
pursued so far generally reveal the following main problem areas : 

.a) Physical 1-0 ports between a computer (host) and a communica¬ 
tions network must be limited to a small number (1 to 3). A 
multiplexing machinery is needed to funnel all host-to-host 
c.essages through a few 1-0 lines. 

b) In order to exchange messages, host processes need some network¬ 
wide name spac“ for addressing each other. 

c) The communications network imposes a maximum message length. 
Longer items must be fragmented and reassembled. 

d) Some messages may not reach their destination. Hence error 
control. 

e.) Unchecked message traffic may flood the receiving host. Hence 
i .. flow control. _ . .„. j 

; f) 1-0 streams should extend ever the network. Hence the need for 
virtual links between processes. 

■ g) File transfer between different hosts. • 

h) Job submission to a distant host. 

‘ . . . . i 

■ j) Communications between various servers and terminals. 1 
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k) Data conversion end reformatting.' 

l) Distributed data base management. 

m) User identification, accounting. * " 

n) Information centers, ana how to get help. 


There is no doubt that users would find overly cumbersome and 
inefficient to use for similar functions as many different 
languages as hosts. This is yet quite awkward to have a Babel on 
a single computer. Consequently network standards must be defined 
for the more popular functions, so that they use the same language 
on every host. 

On a single computer instructions of a program are fed into a 
processor. In a network several processors may be involved 
simultaneously on different -hosts. Conceptually they interact 
with one another as if in direct contact. However, some mechanists 
are required to bridge the ph-sical distance. Therefore additional 
network standards must be defined to reckon with inter-processor 
exchanges. They nave been called "protocols", but they are al'so 
languages as we shall see. 

In Arpanet protocols tend to be limited to the definition of an 
inter-processor language for a particular network usage. In 
Cyclades protocols tend to include also the definition of a user 
language network-wide. 


II. COMMJNICATIONS PRINCIPLES 


System structures : ' 

A 1 ' When analyzing the functions of system components, it is customary 
_i. .to refer to predefined underlying mechanisms called the "lower 
JJ.'level", with which one assumes a set of well defined relations. 

.•'.1 Similarly, each component is supposed to implement a set of 
j..h functions to be invoked by a "higher level" in a well defined 
jJ . 1 manner. Tnis layered approach is now classical and needs no further 
JJ; 1 comment in this context. ; 

-» * i ; I 

_Lc■Confusion may arise when "high" and'low" are taken from a diffe- 
rent realm, such as history, efficiency , - sophistication, priority. 
.1.1 E.g. the SITA High Level Network is actually a lower level 

' structure to a message carrier service’. Particularly, in dealing 
L with message transmission, one frequently introduces another 
cL-i c(outer) level of envelope, which only reflects another (inner) 
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lo.vci of system. These obvious remarks intend to dispel any 
persistent misunderstanding which sometimes degenc.rates into a 
religion war. 

In purely hierarchical systems ,. a,.y level sees on.lv its next 
lower neighbor as being a sir.p..ificd model of whatever happens 
to be. built underneath, (Fig. 1). A frequent terminology refers 
to the h'gher level as the user , ar.d the lower levels as the 
system, while the set of rules governing the mu.uai relationship 
is an inte rface ■ Communications between both levels is often 
straightforward, when they share a common store, end this function 
is not even identified as a relevant subject. 

It may happen that "the system" is so constructed that it cannot 
be.reached by "the user" without resorting to non-trivial mecha¬ 
nisms. Communications become a problem per se, and results in a 
more intricate structure. This is the case when physical compo¬ 
nents are geographically separate, but it also appears in multi¬ 
processor computers (1). A communicat i.on level slips in between 
"user" and "system", (Fig. .2). Is it higher or lower than what ? 

As emphasized previously, hi bn and low levels are just conventio¬ 
nal visions of structural relationship. They do not have to carry 
any connotation of physical or time dependencies. There cannot be 
any formal proof leading to a proper layered structure. In a 
subjective sense, a good one should simplify and help to under¬ 
stand, while conserving flexibility, autonomy, and efficiency in 
implementation. It comes as no surprise that interpretations vary 
widely about the fulfillment of such objectives. As for beauty or 
virtue it relates to personal background. 

Having to deal with a communications level may be a technical 
necessity, but that should not blur the fact that the fundamental 
objective is to interface two levels, ar. simply as if there were 
no communications problem at all. In other words, our simple 
' 2-levcl structure should not be defaced by an accidental component, 
though its presence must.be recognized. This concern results in a 
.3-component structure, where "user" and "system" maintain their 
relationship through a virtual interface , which the communications 
i component endeavors to make look real. As long as "user" and 
"system" are concerned, they only need to know ii: a well defined 
■ manner 'how to invoke functions of the communications component, 

! in order to simulate their mutual direct interaction. In the same 
sense as we have introduced the relationship "user-system", the 
communications component is a sub-svs tern to both. It does not 
; have to make any assumption about the relative levels of the two 
others, as this is only a convention in our mind. If we take the 
viewpoint cf the communications component, the structure rotates 
i 90° to the right, (Fig. 4). "User" and "system" become equal : 
t they are only parties engaged in communications. _ _ , 
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Recap : com tunications are a low.' level transparent to higher 
levels dependencies. Hence they are symmetrical ■ 

Protocols . 

. - ~ , _ i _ , 

Since higher level relative dependencies are immaterial at 
communications level, we use the term "correspondent" to mean 
either one of the two lr.-'els engaged in communications. They 
interfere over a virtual interface, but have no direct exchange 
except through the communications component. The set of rules 
governing the exchange between the two correspondents has come 
to be called a "protocol". It is invisible at communications 
level (2). 

Since we are dealing with computers, information exchanged between 
correspondents are messages. According to the protocol, they may 
contain ASCII text, control fields, floating point numbers, 
relocatable binary programs, or whatever. At communications level 
all messages appear as bit strings. Each message composed by the 
sender and interpreted by the receiver .must conform to the proto¬ 
col. Consequently there must be some mechanisms in charge of 
enforcing rules, ar.d rejecting inacceptable messages. These can 
be viewed as opposite automata, one is the genera tor of produc¬ 
tions of a. language , the other is the recognizer • Productions are 
either accepted or rejected. In the latter, error recovery must 
be performed. Clearly the sender automaton needs some feedback 
when it has to stop generating messages and go to error recovery. 
This means chat communications ere always bi -directional . and 
that sender and receiver automata exchange also control informa- 
'tion in addition to correspondent messages. This is equivalent 
to status codes returned to the caller when using a direct inter¬ 
face . 

Assuming a reliable communications component, messages are only 
rejected when they are .ill formed, in which case error recovery 
requires the sen.er to correct the situation (c.g. when the sender 
is a person at a console). This Should be part of the protocol. 

But rejection may also be traced to message corruption within the 
communications compoient. This is expectable when communications 
use long distance transmission equipment. Here we have several 
ortions : 

a) Correcting communications errors may be included as a normal 

: function of the protocol. This mean? that there is to be some 

departure from the way correspondents would dialogue, should 
they interface directly. On the other hand error control 
. encompasses every possible failure end-to-end ■ 

b) A lower level communications protocol may be contrived, to 
I govern exchanges between sender and receiver automata, and 

correct only communications errors. The corresponding logic 
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is split into a user protocol . assuming perfect communications, 
and a communications protocol , nested in the former, (fig. 5). 

c) One may contend that correcting communications errors should 
Logically be put at communications lev^l anyway. Correspondents 

•would only ’ implement a user protocol, assuming perfect, commu¬ 
nication s. 

d) But no physical .system is perfect. Even though the communica¬ 
tions componer.. would correct errors, there would still be 
unrecoverable or undetected ones,. Consequently the user 
protocol must’be designed to make up for rare yet undesirable 
communications error, lest being occasionally fooled. 

e) It may cost the same at user level to detect and correct rare 
or not quite rare failures. Therefore why put additional mecha¬ 
nisms at communications level ? 

f) If communications arc extremely reliable, it may be sufficient 
for users to rely upon deferred control, so reducing the logic 
embedded in their protocols.. 

g) The argument can go on and on. Again, there is no possible 
proof for the best structure, except by experience. Behind 
all this rationale there is a subjective premise : "I trust 
my part, not yours". But this is such a common attitude in 
human life that it should not be discarded as unreasonable 

in networks. Instead one should identify carefully areas where 
components are to be legitimately mutually suspicious. 


III. DISTRIBUTED MACHINE 

A particular network service (e.g. file transfer) is implcmetted 
as a set of processors available to users in every host, and 
defined by a set of rules, (e.g. the file transfer protoco/). 
While a protocol can be viewed as a language, by extrapolation 
it can also be taken to mean a machine executing programs in- 
that language. Users of that protocol are higher levels in the 
system hierarchy. Within the network at large they interface the 
same service with the same language. Conceptually this set o f 
processors make up a single homogeneous machine, whose components 
happen tn be geographically located in various hosts (3) . We 
call such a construction a "distributed machine”. 

As every abstract view the concept of distributed machine does 
not change anything in the internal structure, which is a set of 
autonomous, distant processors. But it helps to present a simpler 
model at user level, by screening out all considerations not 
relevant to user processing, such as-internal message exchange 
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between corr oonents. The descriptorn of a distributed machine can 
be reduced Co an instruction set. and corresponding actions on 
internal states and input-output (4). 

In order to_execute an instruction ihe components cf a distribu¬ 
ted machine must cooperate, /.Side from transferring operands 
(data), they mute keep a consistent set of internal states which 
constitutes the exccutioc context directing actions to be per¬ 
formed. -Thus, part of t'nc communications established between 
comnonentf is devoted to carrying control information for action 
reports and context updating. 

Communications failures are.not unlikely, and components may 
occasionally exhibit erratic behavior without necessarily go dead. 
In a network environment resorting to manual intervention on 
several hosts may turn out an impossible task. Consequently, 
error recovery should be automated as often as possible. This 
means that execution mechanisms must include back-tracking and 
retry, somewhat .like a few present day computers. 

As can be inferred int litively the critical area in a distributed 
machine is communications. Not because it is intrisically less 
reliable or more.costly than other functions, but because we are 
not yet trained to use it as a basic ingredient of computer ■ 
system architecture. 


IV. BASIC COMMUNICATIONS 


Thc_oirc—rnessac;G__cnsc : 

A component (S) wants to transmit with certainty a message to 
another component (R) . No assumptions are made about communica¬ 
tions reliability : the'message can be delivered correctly within 

■come undefined delay, altered, lost, delivered in several copies, 
etc... The R-state is unknown to S, since any information received 
by S about R relates only to some past point in time. 

'In normal conditions the following sequence of evtnts might take 
place :■ 

; S sends message Ml to'R • ! 

1 R receives message M2 

! R sends M2 back to S 

j S receives M3 ' 

: S compares M3 with Ml and finds them equal 

,At this point can S hold certain that R has received one good 
copy of Ml ? Not quite, unless we introduce some assumptions : 
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- M3 reslly com^s from R 

~ there cannot be an alteration which would turn a bad M2 
back into a good M3. 

A first conclusion is, that messages must contain' two addresses . 

Ml contains R, but also S sc t.iat R can send back M2. And M2 
contains S and P, so that S can chock that M3 comes from R. But 
this is rnly valid to the extent that no other receiver can put 
the R address when sending M2 back to S. Conseq.sntly either of 
the following assumptions must be made : ■ 

- the originating address is put ir. messages off sender's reach 

- senders can be trusted for originating addresses. 

The previous scheme has the obvious drawback of transmitting the 
same message twice. We can reduce the loss of bandwidth, in having 
R send back a short checksum of M2, which S can verify-for cor- 
rectn;cs. Then certainty gives way to high probabi lity, actually 
-as high as desirable with a proper checksumming algorithm. 

Eut wc save even more if S sends the checksum along with Ml, and 
if R checks M2 correctness. Then a simple empty message (Acknow¬ 
ledgement) from R to S can be taken to mean correct reception. 

But more assumptions mutt be made : 

- a receiver can be trusted for checksumming 

- incorrect messages are not acknowledged. 

We introduce now abnormal conditions . Messages may be lost or 
delivered after a very long time. At some point S must decide not 
to wait any longer-for ACK. Hence the need for a time-out 
mechanism. After a number of unsuccessful attempts, S should give 
up. But what conclusions can be inferred ? Any of the following 
causes may have been present : 

- S to R communirations.down 
R to S communications down 

• R down 

- unusual delays 

One cannot conclude that R did not receive the message. Actually 
it may have received all attempts. S ends up with uncertainty ■ 

Ii R is expecting only one message, all additional copies do no 
harm. But if it executes a specific action whenever it receives 
a message, it may not be S intent to have several executions. 
However there is no way to insure that only one copy will be 
delivered to R. Even if S never repeats sending, the communica¬ 
tions machinery may create duplicates ■ Consequently R needs some 
-information to be able to inhibit actions for redundant messages. 
This can be provided in the form of a name attached to the messa¬ 
ge. All messages bearing the same name will be considered as a 
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single copy, ns far as actions ate concerned. But each one is 
acknowledged, since repetitions may he due to the loss of ACK's. 

Once received a message, name is kept within the R context. In 
other words, -R creates a name space of received messages in which 
names must be unique. Before entering a new name it is checked 
against present ones, and if found the message is a duplicate. 


MeRsage_set : 

When S transmits successive messages to R,and receives ACK's. 

_t has no vray to correlate them, if it uses the previous scheme. 
Counting the number of ACK's and messages is unreliable, due to 
duplicates and losses, since' R can cope with duplicates, S must 
insure that every message in the set has been received, therefore 
acknowledged, at least or.i_e. This requires that S keep track of 
unacknowledged messages and R send back named ACK’s . 

With, this additional -feature, message control' is performed on 
each message independently from' the others. V.’c only need a simple 
one-message protocol along with a name space in S and R. A summary 
of mechanisms introduced so far appears in (Fig. 6). 

An obvious weakness of this scheme is the necessity for R to 
retain every distinct received message name in its own space. 
Aside from storage and look up overhead, names cannot be indefi¬ 
nitely unique, or they would grow continuously. Duplicates would 
appear when the name space is exhausted. Consequently a mechanism 
must be introduced to releas e dead names and refill the not yet 
received message name space. Of course both S and R must agree 
or. a common scheme , or else messages would be accepted or dis¬ 
carded untimely. 


No matter hov; S and R draw up their name trade, the communicacions 
system night throw in an old messag e bearing a new name. As this 
would have an undesirable effect, one relies upon another 
atsunntion : 

- the communications system can be trusted for delivering messages 
■within well defined limits ir. time, or not at all. 

i ; 

.Let T.min and T.m.ax be the minimum and maximum delay that a 
message may take to travel from S to R. Then, a message nami may 
be reused after a minimum delay : T.max - T.min, unless repetitions 
are necessary. 


This is a major characteristic of the communications system, since 
■it lias a direct impact on the amount of information which makes 
.up the context of S and R. Indeed, knowing the maximum message 
.traffic., a delay corresponds to a certain number of messages. 
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Let f'. be the maximum number of messages per unit of time. 

Assuming S keeps sending messages it. must hold for possible 
repetition copies of unacknowledged ones, viz : 

2.H T.max 

’ ... - . e 

K must hold.for possible duplicates the'names cf last received 
messages, viz : 

M (T.max - T.min) 

As' can be inferred, the value and the first moment cf transit 
celay in the communications system are to be taken into account 
in S and R design parameters such as buffer length and time-out. 
This is an example of cros s-level interference within the system 
structure. In order to meet the time deviation requirement, the 
communications system may contain a built-in mechanism to exter¬ 
minate outdated messages. Nevertheless, there is always some 
marginal probability that a stranded message be delivered out of 
• the regular time span. 

is' . . . . . 

At this point it/clear that the reliabilit y of basic communications 
relics upon statistics . No control mechanism is 100 2, safe, it 
only reduces the undetected error rate to a lower figure. The 
basic scheme outlined so far makes some assumptions about the 
'■ good behavior of the correspondents. It also assumes a somewhat 
predictable tr ansi'. time in the communications system, but nothing 
else. Eventually error detection is based on the proper management 
of a message name space, without eradicating completely failure 
i possibilities. Therefore some room is left for more stringent 
control depending on the actual environment. 

All basic communications protocols stem from the above scheme, 

. which is primarily a simple scnd-receive-acknowledge sequence 

for each individual message. Their differences are in the way they 
manage their message name space. In the following v.’e illustrate a 
few typical communications protocols. 

1 

Jfj IS0_b i _sic mode : 

i ; . 

It is termed ; basic mode control procedures for data comir.unica- 
-jft ; tions systems (5). As customary, protocols controlling exchanges 
yv over a transmission line are called procedures ■ This protocol is 
—intended for data exchange between a master station (compute.) and 
yy’Slave stations (terminals) through multi-drop lines. Using wires 
-v, allows additional assumptions about the communications system : 

jiy - there is no duplicate message j 

messages are delivered in the same order as sent. : 

mr Every message is acknowledged, and there is only one message in 
--T; ,transit at any moment (alternate). But in many cases acknowled- 


i 


i-i'. Swi 1 I'p' N 1 ■ • 5 : - > '"■'.l \ Vi' .;•> l M,m ; 11 ‘ i i: • ■. w. 

1 !!!,.; h , I \ j . i . < .1 \ . ; '■> 

I iu.i! 1 i -,[■ i Swi : ii ;, -J X ■; 7.i.i' h''. . I n.’i vJl 1 mini 

^ .. i . ■ . ■ v 


\ . 










gcmc-.r, t s arc in the form of special messages, carrying other 
meanings, (NAK, EOT, ENQ) . This is a typical excmplc of mixing 
two levels of protocols, one for message control, the other for 
syntfx correctness in data and device control. 

• i 

Since there is never more than one outstanding message, they have 
no name. However acknowledgements may have two different names, 
alternately, to allow checking for not loosing any, This means 
that message names '0, 1) arc implied by the sender. As long as 

no two successive ACK's are lost, it allows the sender to diffe¬ 
rentiate between an ACK or message loss. But not so for the 
receiver. Therefore, error recovery belongs to the high level of 
the procedure. 

ISO_HDLC : 

This is again an attempt to mix a message transfer protocol and 
a component operation protocol (6). Several messages may be sent 
and acknowledgements de f er red,This means that the communications 
,. system may have a storage capacity of several messages, as store 
and forward networks do. But without stating it explicitly, the 
draft standard assumes sequentia l communications, i.e. message 
' names are sequence numbers and must be received in order. 

The message name space is typically numbers 0 - 15, It is reused 
in a cii/cular fashion, by releasing names of acknowlodged messages. 
, These are only accepted in the correct sequence, therefore any 

acknowledgment stands for all previously numbered ones. As in our 
■ ■ basic scheme, the number they carry i;elates to the message, being 
acknowledged. 

- BBN__ARPANET : 

This one is used for inter-TMP exchange over telephone circuits 
g (7). Thus, only the sender may create duplicates. The message 
_ 1 _._ name space is 16. It is managed in 8 pairs. For each pair both 
.names arc used alternately. Conceptually this is equivalent to 8 
j_g' autonomous parallel channels controlled by a 2-nan:e alternate 
ip procedure. Since only one message can be in transit on each 
: I channel, two names are enough to tell duplicates (8). Acknowled¬ 
g'd'gements are control bits tacked on reverse messages. They carry 
J". 'the acknowledged message name (odd-even bit), and can be sen* - 
■J redundantly> the same way as regular messages. 

i 

Jfj f‘cssage_nair.e management : ■ I 

-rqg Like any other space the message name space may be managed using 
— well known techniques depending on environment constraints. E.g. 

“ circular .space with IN and OUT pointers (HDLC), individual table 
-rj entries (BBN), dynamic allocation of chunks, degenerate 1-name 
;case (ISO basic mode). It all depends on the size of the space, 


W '■! P ; ■ V-,; 

1'';!.i! Si/'.- T\ j .i' i : .Hi \ I V 
If.. '! f,-; ^ ■ I- ! ■> ■ 


i 1 [ i 


'Ll .Il-PL 


. . \ 










1 2 . 


i.c. of the storage caoacity bet'..’P2n sender and receiver, ana 
assumptions made about the communications system (duplicates, 
losses, sequencing). As a result, designing a protocol is a 
matter of good balance between reliability and efficiency. There 
■is no ultimate solution. E.g. for packet communications over 
transmission lines, it seems that a ABN-like procedure is'the 
most efficient (2). 

In end-tc-end protocols encompassing intricate '..nd obscure inner 
levels, users may want to taka every reasonable precaution to 
avail themselves with reliable communications, no matter what 
happens out of their area of control. As we have seen, the basic 
scheme provides for safe communications, but may require a large 
name space, to cater both for delays and duplicates. A way around 
this overhead problem consists in "clipping" out the name space. ■ 
to reduce the active area to a narrow window , which car. be twitched 
on at some intervals of time. Since transit delays are not 
randomly distributed (they are more like Poisson), the window can 
be set to focus on the main cluster of messages in transit. Thus 
duplicates are either recognized or rejected as irrelevant. Some 
proportion of regular nessages ere also rejected, because they 
fall off the window, but the - , are retransmitted. A good balance 
must be found between space and transmission overhead. One more 
remark : no message sequencin g is required. Sequencing is a 
particular case when the window of acceptable names is reduced 
to one. 


Error_recovcry : 

A basic communications protocol is nonetheless an instance of a 
distributed machine, to which general principles apply. Once a 
correspondent has got out of hand, due to unanticipated failure 
of critical parts, or a protocol flaw, exchanges are meaningless 
until a common state of agreement is reinstatea. Consequently 
mechanisms are recessary to direct both automata to a recovery 
procedure. 

.One of the correspondents may discover an error condition and 
decide for itself, buc it must insure that the other will follow 
on. Therefore control messages unrelated to the regular message 
.traffic should be included in the protocol. In case the other 
:omponent cannot be made to go to recovery state, the healthy 
correspondent should report an error to its next higher level and 
reset its state. In any case, recovery may be requested by the 
higher level if it detects an'inconsistency not visible by basic 
communications (syntax error) . 

Following an error, correspondents can no longer count on their 
execution context, which may be inconsistent. But we have seen 
.that this context (name space) is necessary to detect losses and 
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duplicates in oncoming messages. Consequrutly all traffic (except 
error control messages) arriving after at. error is detected should 
be discarded. 

Recovery consists in cleaning out the context in' " backspacing" 
up.to a poinc in past 'traffic Which' both parties consider srfe. 

It may be a prior checkpoint, or may result from, a negotiation 
according to a recovery protocol. Or.ce consistent contexts have 
been reinstalled, regular traffic is resumed-, Since both corres-. 
ponderits possess the same naming scheme, they can usually restart 
from the earliest unacknowledged messageunless directed other¬ 
wise by the higher level. 

Checksumming : 

Ir. some cases parity codes are used, but th ;ir efficiency is 
limited in serial transmission. More efficient techniques are 
based on cyclical redundancy codes (CRC), which can yield an 
undetected error rate less cr.an ! Lit in 10^0 with 1000-bit 
messages and )6-bit CRC. ■ . 

Due to the substantial time which would be required for software 
checksumming, this operation is usually done by the 1-0 haedware. 
However, in store and forward systems, checksums arc stripped off 
on input, and recomputed on output. In the meantime ir.es sages may 
be damaged when they lay unprotected. This is r. present weakness, 
which could be eliminated with an end-to-end checksum. 


V. USKR-TO-USER PROTOCOLS 
Basic level : 

__'J When two user programs running in different bests want to start 
communicating the least’they should be able to do is to cxchs ,.ge 
simple messages , since any to.e sophisticated tool requires an 
Jy initial set up based on messages. This allows bootstrapping 
_;J whatever protocol they night want to use for private or experit.err 
tal purpose. Furthermore many simple tasks can be implemented 
JJ quickly with a few cormunicatior primitives, particularly when 
J ; they are limited to a straightforward dialogue. However, what can 
JJ^ they send messages to ? . 

j 

JJ Subscribers : j 

i s ■ 

It would be unpractical to address messages with names as used 
t." locally in each host, because formats would be dependent on 
■my particular operating systems. They might' also be ambiguous, or 
;unpredictable when a user process is given a name dynamically. 
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It; is much more convenient to create a ne twork-wide name space , 
and assign subscriber numbers in a structured manner, in the same 
vein as P.0, Box 624S2, Zip 53017. 

.. .-For .convenience in routing messages V'.rt of the subscriber name 
can be a geograph;cal locator . like region, city, host. Without 
being a compelling feature, it certainly saver, tine and overhead 
not to have to look up a general network directory to find out a 
•' subscriber location. However "floating" subscribers are perfectly 
acceptable as long as someone pays fbr the associated cost. 

It is also more convenient to assign permanently subscriber names 
to correspondents such as human us^r, terminal, server process, 
sub-system. As the total number of subscribers is likely to be 
much larger than the number of simultaneous active correspondents, 
it may be contended that using too large a name space carries 
transmission and storage overhead. But if there were a dynamic 
allocation of subscriber names, some, other permanent names would 
have' to be used anyway for correspondents to get in touch initia¬ 
lly. On the other hand this-problem is already well known in areas 
such as file systems. Overhead can be reduced by building tables 
■- of "active " subscribers, while others reside on secondary storage. 

Ports__-_hinks : 

Most existing software use the concept of ports to defer till 
execution time the binding of data streams and 1-0 devices, or 
v files. Conventional intcr-process communications are also modeled 
after 1-0 streams. Distributed activities, distant site periphe- 
rals or files require cross-network binding. From communications 
/ standpoint, it is somewhat similar to connecting two subscribers 
in the telephone system. Software lin ks should be established 
- between corresponding ports. Again, we have the same problem as 
• in addressing processes, Since port names are local, they are not 
suited for network naming, 

-A first solution is to use global network names as a substitute 
w ; in exactly the same fashion as we have introduced subscriber 
v names. This is the Arpanet way (10). It requires dynamic alloca- 
tion of global names as anchoring points for' port-to-port links. 
Since these names (sockets) are managed at host level, they 
■ : require allocation to users either on a permanent or dynamic basis. 
-.'-.When it is dynamic, some■preliminary protocol must take place to 
--- exchange socket names before setting up a link. ; 

! " 

■— Another solution is to use network names having a well defined 
format, but local to a subscriber. This is the Cyclades way (11). 
;;; No allocation is necessary, as names are given by users. Further- 
more they are only paired at link set up, which does not require 
--- prior knowledge of the opposite name.' Thus, they .are transient 
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names, because links and pores exist only during execution of a 
process. 

Since a data stream requires some error and flow control, it 
always has to be matched by a reverse stream. Thus one has the 
choice to use uni-directional links and set up two for every 
stream, (Arpanet), or to use bi-directional links (Cyclades). 

Sequencing : 

This concept applies only to a link .- It means that messages are 
delivered to a port in the same order as they have been sent. 
This is so obvious in wired communications that not everyone 
questions the very necessity of that property. In data streams, 
sequencing is intrisic. But 'one may think of Other types of data 
transfer for which sequencing is immaterial , as long as no data 
are altered. E.g. transferring an index-sequential, or direct 
access file ; or funneling independent transactions toward a 
common processor ; or collecting statistics ; or transferring a 
sequential file to a SORT processor, etc... 

The alternative is : should all communications be sequential 
because it is often required, or should that be left up to the 
user ? Indeed, a multi-node packet switching network is not 
intrisically sequential, and it takes overhead and restrictions 
to make it look that way. There is no definite answer yet, as we 
do not know enough about economics and user experience. 


K\_ r tnts ; 

'' Like 1-0 streams, links are subjected to unexpected conditions : 

. _ accidental closure,- message loss ; or they have to relay conditions 

' noticed by a connected process. In other words, in addition to 
data lines a link should have interrupt lines, so that a signal 
. : can jump ahead of the data still in transit. This can be obtained 

... v;ith higher priority messages over a link, or by having a dedica¬ 
ted link for events. In 'case of erratic behavior of a corre'-pon- 
;;m dent,"escape" events should be picked up by the addressee 
( j.i controlling environment. Eut this can be a dedicated event link. 

71 1 

. ■ Fragmentation • l 

At some point in the communications path there is a m aximum 
message length. The packet switching principle is based on sl.-rt 
---• messages, typically a maximum, of 500 to 2000 bits. This is pcrfec- 
-pr tly satisfactory for conversational traffic with short terminals, . 
—j- short transactions, or control messages. This is much too short 
-j-p for data processing, with 500 to 2000-character records, or device 
-- handling using blocking factors. Not to mention file transfer. 

Therefore logical user messages must be broker, down into fragments 
and later on reassembled in the proper order, when they are too 
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Whether this operation should be performed only once per message, 
or at several levels, is purely a matter of economics or techno¬ 
logical constraints. A typical packet switching network using 
mini-computers cannot store very Long messages. Furthermore, they 
would block i.-O ports, and delay: other messages. Therefore only 
sub-fragmentation can be performed within the communications 
network. Ano ther level is required anyhow. Thun what is the 
benefit of having fragmentation within packet switching, vs. the 
resulting constraints ? This is an open question. 

A common answer is that it saves on host overhead , notably 7-0. 
But if we look at the way many an operating system handles commu¬ 
nications 1 - 0 , overhead can be traced back to poor design. 
Transmission line 1-0 should be an independent system , possibly 
wired-in or micro-programmed, instead of a nightmarish kludge of 
interrupts, clock routines, scheduling, argument checking, 
register saving, ... except 1 - 0 . 

If users want to send cr receive long messages, they have to 
provide some corresponding buffers. It may be an appropriate 
place to fragment and reassemble. Or is it ? 

control : 

' If one assumes that lower mechanisms are error free, then error 
control should be of no concern at user level. But everyone is 
,, entitled to his own suspicion. If user protocols do not provide 
for end-to-end control, at least as an option, likely some users 
will want to put their own. Bit pattern control may usually be 
entrusted to lower levels, where it is done quite efficiently. 

But messag e naming and acknowledgement may well be organized ct 
. user level, because it allows a variety of techniques depending 
on the type ol traffic. 

E.g. in a conversational application, control may be based on 
message syntax and contents ; in a D.P. appiicition, it may be 
7 done by matching a master file, checksumming a record, adding up 
-.. 7 ' fields ; in a program library, there are often specific redun- 
dancies which may be taken advantage of. 

.:•> I 

■'-it,There may be some inconvenience to handle time-outs as interrupts 
: at user level, because operating systems do not always offer 
"if adequate user services in this area. On the other hand system 
* 7 " primitives such as SEED, RECEIVE, WAIT, may be equipped with a 
-in- built-in time-out and an appropriate return status when the user 
77 process is awakened. 

■if, Likely some error detection and recovery are exercised at iower 
7 i icvels . This might appear redundant, since it usually applies 
only to some sections of the communications path. But it is not 
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useless, because it allows quicker detection and reporting of 
component, failures, and recovery at inner levels costs less 
overhead. Nevertheless, there arc always anomalies which cannot 
be detected or corrected at lower levels, nonce an error recovery 
procedure is always necessary at userle/el. It may be tailored 
. -to the failure rate reported at this level. 

However it can be argued-whether it is desirable to put error 
control entirely in user's hands, since he may not be trusted 
to always do tno right thing, and unjustified complaints can 
deteriorate the network image. Probably a standard error con trol 
mechanism should be offered as an alternative, so that casual 
users have not to make any effort in v.’orkir.g one out. This can be 
a.simple acknowledgement of- named messages . 

T1ovj_co Ti t it o 1 : 

For reasons similar to error control, one may contend that users 
are in the best position to know hew; much storage . they will have 
available and expected rates of data transfer. Since throughput 
and overhead are closely tied with flow; control, it may be the 
best (or the worse) choice to leave it up to the user. Flexibility 
goes with some risks of inappropriate tuning. But it is certainly 
■ . easier to correct particular user situations than to redesign and 
phase in a network standard flow control. 

It is clear that buffering at lo wer levels cannot go without its 
own flow; control. The same is true for a communications network. 

" Then one might wonder whether'all these layers of control are 
really useful or whether they result from mutual suspicion and 
inadequacy. Although the latter may be true, it does not seem to. 

' be the fundamental motivation. Flow control is intrisically a 
resource shar ing exercise between different flows and different 
; ‘ users. There is nowhere in a system an ideal observation point 
“ ' from which all resources could he apportionned. Depending on level, 
' ' one sees different flows and resources. E.g. if a user interleaves 
a diagnostics output stream ; vid a file inquiry onto the same link, 

" he is the only one in a position to control each flew independent- 
■ ly and to divide up the link bandwith. This means that flow 
control, like resource management, is a layered ana distributee 
~r,set of functions. Thus some of it belongs to user level . 
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VI. SERVER - PROTOCOLS 


i 


Server_lcvel : 

Customarily a server is a non-trivial user system Co which commands 
are adressed directly in seme Corn of high level lingo. It is.an 
abstract machine which converts the traditional user interface 
into a more sophisticated and specialized one. Servers are accessed 
by "users ,: . In this chapter Che term user shall mean user or a 
server. ... ' ' ■ • 

We shall take an example with the Arpanet file transfer protocol 
(12), just to show typical communications aspects of the. server ■ 
level, (Fig. 7). Transferring a file requires the cooperation of 
two machines, a "reader-sender" (RS) and a "receiver-writer" (RW); 
But these machines cannot get to work without being fed a program 
specifying all parameters pertaining to .the files being worked on, 
and the operations to be performed. This program is conveyed into 
both RS and RW in a conventional command' format through. TELNET 
links, a lower level protocol for character string transfer. Sinct 
RS and RW do not "understand" character strings, they are assisted 
with "front-end" (SFE) processors translating commands into an 
executable form. This is the well known structure of a lancuane 
intcrprctcr ■ SFE's are syntax analyzers ; RS and RW are semantic 
actions, 


’ Commands arc sent from a user front-end (UFE) in charge of inter- 
. . . facing with the external user (typically a conversational 

terminal), and producing commands for SFE's. UFE can be in a thiul 
. hoot. After execution commands are acknowledged with status reports 
flowing back to UFE via the TELNET links. 

. The file transfer protocol specifies in every detail the relations 
.' between UFE and SFE's. It does not specify an external user lan- 
guege, although commands are represented with character sntngs 
which could well be a direct console input-. Similarly status 
reports are made up of a (specified) printable code, plus an 
J.t. (unspecified) comment. Here follows a sampling of commands : 

'T.T | class A class B class C ! 


USER 

BYTE 

RETRIEVE 

LIST 

PASSWORD 

MODE 

STORE 

ALLOCATE 

ACCOUNT 

SOCKET 

APPEND 

RESTART 

REINIT 

STRUCTURE ' 

DELETE 

ABORT 

BYE 

TYPE 

RENAME 

' ■ 
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h.B. Spelling is occasionally a shore form of the above v.'ords. 

Class A commands set up a user context. Class B commands set up 
a file context. Both make up the exec u tion context of the server 
machine. Class C commands are instructions ■ 

The set of components on (Big. 7) is nothing but a distributed 
machine, with its internal communication machinery for synchro¬ 
nizing its processors. 

From this observation one might draw some thoughts. Since internal 
server communications are machine language, is there any subtle 
advantage to make it look like high level ? Wouldn't it be more 
efficient to have straight forward communication tools tailored 
to exchanging contexts, instructions, and operands in a compact 
form ? On the other hand wouldn't it be rational to have a well 
defined external user language network-wide ? But that's 
sociology. 


, VII, HOST-TCHIOST PROTOCOLS 
Host properties : 

If one looks for the use made of a host entity within network 
mechanisms, one finds that it only serves as a geo g raphical pointer. 
It cannot be allocated, copied, or updated ; it has no attribute ; 
it is just a name . From communications standpoint, it can be up 
or down : it is a device . Within hosts there are subscribers, 
users, servers, files, etc... Hosts are resource containers .' 
Resources are accessible individually from local activities. 

.w They can also be accessed remotely from distant activities distii- 
y buted throughout the network. A communications path is established 
through a carrier network, and a single device comprising modems, 
transmission lines, and 1-0 adapters. For reliability we may want 
to have two, but that is a separate issue., 
i 1 1 

Hosts are organized so that parallel activities can execute 
I: independently, or in cooperation. Each ’activity may communicate 
•J_‘j with other network activities and to that effect calls for com- 
munications mechanisms. As seen previously, these are a subsc r iber 
_iy name space and a gamut of user protocols. They all must share 
_[_n common physical devices to communicate. Therefore we need a tool 
JJ.. I- 1 ' control that mul tiplexing . Furthermore they do not want to get 
i involved in the details of communications technology. Therefore. 

Jv we need a basic communications facility providing straight £orwar4 
_A" message transfer. 
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'i'hese are the three basic requirements for a host kit : . 

- 1-0 multiplexing 

- subscriber name space 

- message transfer 

Practically', for various extraneous reasons, other functions are 
also requir-'.d, such as : - diagnostics, - operator service, 

- measurement, etc... But these are additional real life aspects 
not directly implied in network communications. 

Network control_pool : 

As is instantly visible the three functions listed above are quite 
independent and need not be intertwined. It is even tempting to 
introduce a tree structure : 

a) One 1-0 multiplexer, with one or several paths to the communi¬ 
cations network, 

■ b) An open-ended set of subscriber name spaces, 

c) For each subscriber name .space, an open-ended set of basic 
message transfer protocols. 

3ut this may be somewhat arbitrary. A single level for b and c 
might be more general, since it allows potentially any combination 
of subscriber and transfer schemes. 

Let .us call that set of functions a "network control pool" (N'CP) . 
Altogether NCP's are a distributed machine establishing a cor.tr.on 
lower level interface giving access to any host in any other 
network , provided that matching subscriber and message conventions 
are implemented. 

Design options : 

The network control philosophy just brought about is an approach 
situated at one end of the spectrum of possibilities. Its 
rationale is to delineate self-contained functions which can 'work 
independently assuming only a minimum set of properti.es about 
other components, most of which are actually invisible. Sophisti¬ 
cated services are just a juxtaposition'of simple functions. 
Redundancy in implementation can be reduced by a clever desig” 
of shared sub-routines. 

: Another extreme approach is to bury user- protocols deep through 
lower levels, including the communications network. This is typi¬ 
cal of one of a kind systems carefully tailored to the require¬ 
ments of a particular set of applications. 
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